When an Information Processing Device (IPD) is powered on, it may first undergo a boot sequence to initialize its various hardware and/or software components. The boot sequence may be performed by software having a multi-image boot architecture that can include many code images which may be separately compiled and maintained. The boot sequence may start out by first executing a primary boot code. In general, the primary boot code may be stored in an on-chip non-volatile memory and may be fixed at the time of the IPD's manufacturing. In some cases, the primary boot code can be stored in off-chip non-volatile memory.
After a power cycle (fully off-state to on-state or semi off-state to on-state), the IPD may start executing the primary boot code. As part of primary boot code execution, the IPD may download the secondary boot code or image which may be the next step in the boot-up process of the IPD. The secondary boot code may reside in an off-chip non-volatile memory, and may vary with product and also with product configuration. Different types of memory devices may be used to store secondary boot code, for example, NAND flash, oneNAND flash, m-system flash, NOR flash, EEPROM, ROM, etc. To download the secondary boot code image, the IPD should know the details of the device in which secondary boot code resides (device type) and how to download it (protocol to access the device, how to access the device, how the data stored in the device, etc). As the secondary boot code download occurs during the primary boot code execution, the IPD should have the information (regarding the device in which secondary code is stored and how to download the secondary boot code) in the primary boot code itself. Alternatively, the IPD may be able to derive this information during the primary boot code execution.
Once the IPD finishes primary boot code execution, it may complete the detection of the device that has secondary code, the location of the secondary code in the device (e.g., the address), and how to access the secondary code. In some cases the IPD may download the secondary code form the device to an on-chip memory or off-chip memory, and in some other cases it may only identify the secondary code location and how to access it. After completing the primary boot code execution, the IPD starts executing the secondary code. During the secondary code image execution, the IPD may identify/learn more details of the hardware configuration of the system (what type of system, devices connected, features of the system, system memory size, width, location, protocol to access the system memory, etc.) and also some level SW configuration.
As described above, to download the secondary code, the IPD should determine the device type and its method of access. As there may be different types of devices which need to be accessed during the primary boot, the IPD may perform three general steps to realize access to a memory device: (i) device type detection; (ii) bus interface width detection; and (iii) page/sector size determining of the device (when the device is page/sector oriented). The IPD should complete these steps before it can access the secondary code in the device.
Accordingly for proper operation, an IPD may identify the page/sector size of a non-volatile flash memory device to which it may be connected. Assuming the IPD identified the device type in which a secondary boot code is stored, it can then detect the format in which data is stored. Certain types of flash devices store data in page format (e.g.: NAND, oneNAND, m-system, superAND, etc.). The page size of the device may vary with its density and type of the device. Page size of a given flash device can as low as, for example, 128 bytes and as high as 8 Kbyte, or higher.
With increasing flash device densities, the page sizes are correspondingly increasing. Different techniques may be used to detect the page size and interface bus width of the device by the IPD. One conventional technique may encode the page size and/or bus width by having dedicated external pins to the IPD and the value driven to these pins can indicate the page size of the device and/or the bus width. This approach may be very simple; however, the number of dedicated pins required to support all different page sizes can become large.
Another possible solution may store page size and bus width information in the first page of the flash device, and hardware logic may read the first page from the flash device during the primary boot execution (either the IPD forces the hardware to perform this functionality, or the hardware logic automatically detects and reads the first page). The solution may have no protection against random errors that can occur during the first page read. Flash devices may be prone to random errors, and if the data in the first page gets corrupted either in the flash memory or while the IPD is reading the data from flash memory, there is a possibility the IPD can incorrectly detect the page size which may result in catastrophic failure. Error protection can not conventionally be added at this stage as the page and data format is not known to the IPD at the boot-up time.
To improve the protection against read failures, the page size and bus width may be encoded using unique numbers, known as a magic numbers, which provide protection against random errors. Page size and bus width may be encoded into a unique magic number and put in the first page of the device. The IPD may detect the page size based on the magic numbers stored in the first page and then accesses the secondary boot code based on the page size. This implies the secondary boot code/image must be compiled and maintained for each flash device (page and bus width sizes). As the number of different types of flash memory devices continues to grow, it may become costly to develop, manage, and maintain separate software builds which correspond to different flash devices.
Accordingly, there is a need for a new automatic page size detection approach which may support flash device configuration utilizing common software in order to reduce development and maintenance costs.